1. Field of the Invention
The present invention relates to a system and method which permit data output from the debugging of a software application to be re-utilized. More particularly, the present invention relates to a system and method whereby data output from the debugging of a software application can be run through a new set of debugging criteria without requiring re-execution of the application.
2. Description of the Related Art
Newly created software programs or applications typically contain a number of inadvertent programming errors, known as "bugs". Following the creation of an application, the application is typically "debugged" in order to find, correct and/or remove the bugs. While some errors or bugs can be relatively easy to find and correct, other bugs may be quite difficult to locate, appearing only under certain circumstances or conditions. These bugs are much more troublesome.
In today's marketplace, error filled or buggy commercial programs will not be well accepted. However, debugging a program or an application is one of the most difficult and time consuming, and therefore expensive, steps involved in creating a computer program or application. While a programmer may be able to manually debug a short or relatively simple program by following the logic from a version of the program in a human perceivable form (such as source code), such is not the case with relatively long or relatively complex programs, which may include numerous calls, variables, subroutines, etc.
Typically, a program is put through a number of test scenarios to make sure it functions properly. A number of debugging programs or tools known as debuggers have been developed to assist the programmer in debugging applications. Debuggers permit programmers to view the execution of the software program and provide some mechanism for controlling the execution. Good debuggers also give the programmer control of data values and logic branches so that the programmer can force all possible paths to ensure good testing.
One component for debuggers is the trace facility. The trace facility function captures and presents textual information regarding the history of a given execution path, providing a history of control flow, data movement and other related information pertaining to the program or application being debugged during the debugging session. This form of information is invaluable when attempting to debug problems that cannot easily be isolated to one module or one small, localized set of modules.
However, the volume of information provided by the trace facility can grow to such large proportions as to obscure the few relevant pieces of information that the trace facility has captured. That is, the first set or first few sets of trace or filtering criteria will rarely provide the ideal level of trace information. In each such case, the programmer must readjust the filtering criteria and re-execute the application being debugged under the appropriate test scenario. While changing the filtering criteria is a small task, re-executing the test scenario can be time consuming and tie up valuable computer resources and therefore be quite expensive. The only alternative presently available is to sift through the unnecessary data to find the relevant information, which can also be time consuming and expensive.
Accordingly, a need has developed for a trace facility component that can rapidly and inexpensively permit a programmer to hone in on the problematic portions of the program.